Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP27。

這系列文走到這裡，其實一直在解決同一個核心問題的不同面向。

AI 說「完成了」，跟這件事真的完成了，是兩回事。 所以我們把「怎麼算完成」正式寫成一份行為契約，幾條規則整理起來大概是這樣：

1. 先講清楚退出條件：動手之前，先講清楚目標、範圍、以及一個可被觀察、可被測試的「完成」定義，而不是一句「感覺應該可以了」。
2. 驗證要誠實：沒有真的執行過的檢查，不能宣稱已經驗證；一個指令回傳成功，不代表它驗證的正是原本要解決的那個問題。
3. 標記未驗證的事實：無法確認的內容要明確標成「未驗證」，而不是含糊地當作已知事實講出去。
4. 失敗兩次就要換方法：同一個做法連續失敗兩次，就該停下來重新界定問題，而不是無限次地用同一招硬撞。

這份契約的完成檢查清單，會在每次任務結束前被拿出來對照一遍：輸出是不是真的存在、驗證結果有沒有實際證據（指令加輸出、檔案位置，或使用者確認）、原本失敗的檢查是不是真的重跑過並且通過、還有沒有殘留的敏感暫存檔案沒清乾淨。

這個契約提醒我們一件很現實的事：測試通過不一定等於需求已被真正觀察到，指令執行成功也不一定等於現實世界的狀態真的照預期改變了。 遇到遠端不可達、證據不足、或連續兩次嘗試都失敗的狀況，AI 應該停下來重新界定問題，而不是無限堆疊猜測，硬把「看起來完成」講成「已經完成」。

這加起來其實就一句話：完成要有可觀察證據；沒跑過的檢查不能宣稱已驗證，失敗兩次就要換方法。

完成條件寫成了通用契約，但有些領域知識本身，就足以構成一組更具體的完成判斷。

下一篇來聊這個。